Service-oriented architecture (SOA) is a rapidly growing design option expressing a perspective of software architecture that defines the uses of loosely coupled software components such as services, applications, and processes. Using such a service-oriented computing paradigm, applications are increasingly implemented by means of composition of services and/or processes in order to ease both the reusability of modules, single processes, and/or services/service applications and the reconfiguration of workflows representing such composite services and applications.
With regard to security, services, processes, and applications of a composite application are autonomously performing user authentication and authorization. Although autonomously performed security checks are a prerequisite for the dynamic integration of services, processes, and/or applications and the realization of inter-organizational value creation chains, they lead to observable performance drawbacks, in particular regarding to rarely modified, but frequently executed services, processes, and/or applications, i.e. static ones.
In other words, due to authorization autonomy, requests to a composite application are repeatedly and, thus, potentially redundantly evaluated. Therefore, a separation of access control from a composite application brings about significant performance drawbacks.
Technical Terms
Following technical terms are widely used in the following. The terms may refer to but are not limited to the subsequently given explanations.
Workflow:
In general, a workflow may be considered as an operational aspect of a work procedure: how tasks are structured, who performs them, what their relative order is, how they are synchronized, how information flows to support the tasks and how tasks are being tracked. Accordingly, a composite application comprising a set of sub-applications such as Web services, loosely coupled in a service-oriented architecture may be modeled in a workflow wherein an invocation of any of the sub-applications may be represented by a sub-activity. A sub-application may be a self-contained software component (e.g. a Web service). The workflow may represent interdependencies between the sub-activities which must be considered when execution one or more of the represented sub-applications. In particular, workflow may be specified using (Web) service composition languages such as BPEL, BPM1, WSFL, or SWSL.
Control Flow:
In general, control flow may refer to an order in which individual statements or instructions of a computer program (in particular an imperative computer program) are implemented. With regard to workflows, the control flow of a workflow comprising a plurality of sub-activities may specify an order in which the sub-activities are performed and/or executed. For example, the workflow specification language BPEL is based on imperative program instructions.
Policy:
A policy comprises one or more access control rules. An access control rule may substantially comprise a condition, which must be fulfilled by a subject or an identity such as a requester in view of a requested application and/or service. A condition may substantially be a Boolean function, which may evaluate to true or false. A policy may be specified using a policy specification language such as XACML.
Consolidated Workflow Policy:
In general, a consolidated workflow policy may be inferred from a set of individual (security) policies through a bottom-up analysis of the workflow. More particular, the consolidated workflow policy may be based on the individual policies of the sub-activities comprised in the workflow and may have the following properties: (1) The consolidated policy should be as restrictive as possible to block requests which do not comply with the integrated sub-activities' policies (wherein unsuccessful executions of the workflow are prevented at an early stage), and (2) the consolidated policy should grant all necessary privileges to make the intended functionality available to legitimate users.
(Workflow) Tree:
In general, a tree may be a data structure that emulates a tree structure with a set of linked nodes. Each node in a tree may have zero or more child nodes, which are below in the tree (by convention, trees grown down, not up as they do in nature). A node that has a child is called the child's parent note. Nodes having at least one child are called inner nodes or structured nodes. Nodes that do not have a child node are called leafs. With regard to a workflow, a workflow specified in BPEL may be represented by a (workflow tree) wherein its inner, i.e. structured nodes may be represented by structured activities which may represent an execution command (e.g. whether subsequent activities may be executed in sequence or in parallel) in the workflow. Accordingly, the sub-activities of the workflow may be represented by leafs in a corresponding workflow tree. A node in a tree may be associated with a label (such as a string or a number), e.g. specifying the position of the node in the tree.
(Execution) Path:
An (execution) path, for example through a workflow, may be a connected sequence of sub-activities (which are connected by structured activities) in the workflow such that the workflow is in an exemplary aspect entered at its staring point and finished at its ending point.
Path Label:
An execution path in a workflow may be enhanced with a label, referred to as path label, which represents the positions of the sub-activities lying on the execution path in a corresponding workflow tree. In particular, each sub-activity may be labeled with information necessary to describe the position of the sub-activity in a workflow tree.
Authorization Trie:
In general, a trie (or prefix tree) is an ordered tree data structure that may be used to store an associative array where the labels are strings. The position of a node in a trie shows what label it is associated with. All the descendants of any one of the nodes have a common prefix of the string associated with that note. In an authorization trie, the path labels of executions paths of a workflow may be ordered, wherein a user is authorized to execute the contained execution paths. In other words, a path through the authorization trie may specify a path label of an execution path. Since a path label represents the positions of the sub-activities lying on the corresponding execution path, a prefix check may be performed in order to determine whether a sub-activity lies on that execution path or not. In particular, it may be checked whether the label of the sub-activity is a part, i.e. a prefix, of the path label.